Skip to content

Conversation

@krassowski
Copy link
Collaborator

@krassowski krassowski commented Nov 15, 2025

This PR addresses the issue of frontends having to re-render widgets (with loss of state!) when any ydoc actor changes the source of the document on top-level. This should be owned by jupyter-ydoc because it is the emitter of the signals, and source of truth about primitives (cell/notebook/unicode) structure.

For a future PR: repeat on JS side.

@krassowski krassowski added the bug Something isn't working label Nov 15, 2025
Automatic application of license header
@krassowski krassowski marked this pull request as ready for review November 16, 2025 22:41
Comment on lines 287 to 289
# we need to compare against a python cell to avoid
# an extra transaction on new cells which are not yet
# integrated into the ydoc document.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could use new_ycell.prelim.get("id") and avoid storing the python cells, or only store python cells and create ycells when needed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion, I went for only storing python cells as to use prelim we would need to check if a cell is integrated or not and would get more overhead.

index += 1

except Exception as e:
# Fallback to total overwrite, warn to allow debugging
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What kind of error are you expecting?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not expecting any, unless there is something around concurrency that could go wrong. This is just out of abundance of caution when making a change deep in the stack; do you think we should remove exception handling and the fallback?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concurrency like in async? Because this function is not async.
I would rather let the exception propagate if the logic here is wrong, but no strong opinion.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rather let the exception propagate

Done in b97f4de

Copy link
Collaborator

@davidbrochart davidbrochart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Mike.

@krassowski krassowski merged commit 359c16e into jupyter-server:main Nov 17, 2025
9 of 10 checks passed
@krassowski krassowski deleted the more-clever-set branch November 17, 2025 12:04
@krassowski
Copy link
Collaborator Author

Thank you for the review!

I will release this in 3.2.0 now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants